Недавно компания Cisco анонсировала скорую доступность бета-версии своего виртуального распределенного коммутатора Cisco Nexus 1000V 2.1, который не только получит много новых возможностей, но и будет иметь бесплатное издание - Essential Edition.

Напомним, что на данный момент актуальная версия коммутатора Cisco Nexus 1000V 1.5.2 работает на VMware vSphere 5.1 и с vCloud Director 5.1 и уже имеет поддержку технологии VXLAN:

В октябре этого года компания Cisco планирует добавить следующие возможности в Cisco Nexus 1000V 2.1:

Поддержка TrustSec SXP позволяет сегментировать виртуальный датацентр на несколько зон безопасности, защищенных политиками, по тэгам SGT:

Появится полноценный плагин к vCenter:

Технология vTracker позволит отслеживать различные процессы и события в сети виртуальной инфраструктуры (например, миграции vMotion):

Модули VSM можно разносить по двум датацентрам в конфигурации Active-Passive:

Теперь о различиях платного (Advanced Edition) и бесплатного (Essential Edition) изданий Cisco Nexus 1000V 2.1:

Пользователи Cisco Nexus 1000V с активной подпиской получают версию 2.1 бесплатно, а также компонент VSG (Virtual Security Gateway) в подарок, который больше отдельно не продается (т.е. его нельзя прикрутить к бесплатному изданию):

Виртуальный распределенный коммутатор Cisco Nexus 1000V будет доступен не только для VMware vSphere, но и для платформ Microsoft Hyper-V, Linux Kernel-Based Virtual Machine (KVM), а также Citrix XenServer. Напомним, что в VMware vSphere его можно использовать только совместно с изданием vSphere Enterprise Plus.

Во время проходившей в конце августа конференции VMworld 2012 компания VMware выпустила интересный постер - "VMware vCloud Networking Poster".

Из этого постера можно узнать о том, как работают 3 основных составляющих сетевого взаимодействия виртуальной облачной инфраструктуры VMware:

• vSphere Standard Switch (VSS) - обычный виртуальный коммутатор на хостах ESXi.
• vSphere Distributed Switch (VDS) - распределенный виртуальный коммутатор, предоставляющий функции централизованного управления сетевой инфраструктурой через vCenter.
• Virtual Extensible Local Area Network (VXLAN) - новая технология для облачных инфраструктур, пришедшая на смену VLAN, описанная у нас тут.

На постере приведены различные параметры настройки обычного и распределенного коммутаторов, которые могут оказаться полезными для администраторов, поэтому можно распечатать постер в формате A2+, повесить на стену и обращаться к нему по мере надобности. Он также будет полезен при общении с сетевыми администраторами компании.

Скачать постер VMware vCloud Networking в формате PDF.

Мы уже писали о новых возможностях плафтормы виртуализации VMware vSphere 5.1, а также о принципах лицензирования продукта. Среди новых функций сетевого взаимодействия в vSphere 5.1 появились возможности Network Health Check, обеспечивающие проверку согласованности параметров на виртуальных распределенных коммутаторах VDS и физических коммутаторах, к которым подключены сетевые адаптеры серверов ESXi.

В рамках Network Health Check отслеживается корректность настройки следующих параметров (с интервалом в 1 минуту) для физических и виртуальных коммутаторов:

• VLAN
• MTU
• Network adapter teaming

Делается это средствами Layer 2 Ethernet probing. Сегодня мы расскажем о том, как выглядит на практике Network Health Check при проверке VLAN, основываясь на материалах блогера Rickard Nobel. Для начала в vSphere Web Client для коммутатора VDS 5.1 зайдем на вкладку "Manage" в раздел "Health check":

Здесь мы видим, что функции Health check включены только для параметров VLAN и MTU. Частая проблема администраторов vSphere заключается в том, что настройки VLAN, сделанные в портгруппах на виртуальном коммутаторе VDS, не совпадают с настройками VLAN на портах физических свичей.

Например, для портгруппы VDS настроен VLAN 200, а сетевой администратор, который настраивал VLAN для портов физических коммутаторов, куда ведут аплинки серверов ESXi, пропустил один из портов физического коммутатора при настройке для пропускания фреймов VLAN 200. Вследствие этого, виртуальные машины могут работать хорошо, однако функции vMotion/DRS могут быть частично недоступны для некоторых из хостов.

Собственно, чтобы вовремя обнаружить такую ошибку, мы и включаем Network Health Check:

Теперь хосты ESXi будут слать броадкасты на все свои адаптеры vmnic, привязанные к VDS, и отслеживать, не дропают ли их порты физических коммутаторов. Эти фреймы будут тэгированы всеми VLAN ID, которые назначены для групп портов VDS. В нашем случе - это VLAN 100 и VLAN 200, которые мы видим в списке портгрупп:

Теперь мы видим новую вкладку "Monitor", где можно отслеживать жизнедеятельность VLAN на хостах. Заходим в подраздел "Health":

Здесь мы видим, что для одного хоста с настройками VLAN что-то не так. Смотрим детали:

Здесь мы видим, что для аплинков vmnic2 и vmnic3 не работает VLAN 200. Теперь неплохо бы в настройках VDS включить поддержку LLDP (режим Both или Advertise), чтобы определить порты физического коммутатора, с которыми связана данная проблема для конкретных аплинков, и не бегать в серверную.

Теперь на физическом коммутаторе смотрим порты, куда включены vmnic2 и vmnic3 командой (в данном случае команды для коммутатора HP):

# show lldp info remote

Мы видим порты свича, куда включены проблемные аплинки хоста. Теперь смотрим, для каких портов настроен VLAN 200 командой:

# show vlan 200

Видим, что VLAN 200 пропускается только на порту A13, а порт A14 не пропускает двухсотый VLAN. Исправляем ситуацию, добавляя VLAN 200 для порта A14, командой:

# vlan 200 tag A14

И выводим снова информацию по VLAN 200:

Теперь оба порта на физическом коммутаторе принимают кадры с VLAN ID 200.

Откроем vSphere Web Client for ESXi 5.1 и посмотрим, в каком состоянии теперь находятся аплинки VDS:

Теперь мы видим, что все корректно настроено, и порты физических коммутаторов пропускают нужные VLAN от обозначенных сетевых адаптеров хостов в портгруппах VDS.

Как многие из вас читали, недавно компания Microsoft выпустила RTM-релиз новой версии ОС Windows Server 2012. Мы уже писали о новых возможностях гипервизора Hyper-V 3.0, который приобрел много новых функций и улучшений, что позволяет ему конкурировать с платформой VMware vSphere, являющейся на данный момент лидером рынка. Одним из таких улучшений стал виртуальный коммутатор Hyper-V Extensible Switch, работающий на уровне Layer 2 и предоставляющий возможности расширения функциональности за счет API, доступного для компаний-партнеров Microsoft. Более подробно об этом можно прочитать тут.

Базовыми возможностями сетевого коммутатора Hyper-V являются:

• Возможность изоляции виртуальных машин путём создания частных виртуальных сетей (PVLANs)
• Защита от ARP Spoofing атак
• Защита от DHCP Snooping атак
• Изоляция и ограничение пропускной способности портов коммутатора
• Поддержка VLAN Trunking для виртуальных машин
• Мониторинг трафика
• Управление через PowerShell и WMI

Для тех, кто интересуется подробностями функции Hyper-V Extensible Switch, компания Microsoft подготовила серию неплохих видео:

Также за последнее время появилось несколько полезных ссылок, особенно для тех, кто подумывает о переходе с VMware vSphere на Microsoft Hyper-V:

• Про кластеры из гостевых ОС - Hyper-V, в отличие от vSphere, поддерживает кластеризацию больше, чем 2-х ВМ, работающих не только с FC-хранилищем, но и с iSCSI и NFS. При этом поддерживается Live Migration таких машин.
• Немного про снапшоты ВМ - тут и тут.
• Список поддерживаемых гостевых ОС (клиентских и серверных) - находится внизу страницы по ссылке. Полезно помнить, что официально поддерживается в Hyper-V.
• Описание технологии репликации Hyper-V Replica. Внизу много интересных ссылок, например, документ "Understand and Troubleshoot Hyper-V Replica in Windows Server "8" Beta" с картинками для понимания.

Ну а для тех, кто хочет в целом узнать о том, что новенького появилось в Windows Server 2012, есть вот такая огромная коллекция ссылок.

Совсем недавно мы писали про программно-определяемые сети (Software-defined networking, SDN), концепцию которых продвигала компания Nicira, которая уже скоро стенет частью VMware. Продукт компании Nicira, Network Virtualization Platform (NVP) позволяет создать единый виртуальный пул сетевых ресурсов, полученный за счет логического объединения сетевых коммутаторов и интерефейсов датацентра средствами специализированного программного обеспечения.

На этой неделе компания Oracle сделала ответный шаг на действия VMware по приобретению Nicira: Oracle приобретает компанию Xsigo Systems, занимающуюся технологиями виртуализации сетевой инфраструктуры и, как заявлено, теми же самыми программно-определяемыми сетям, что и Nicira (однако ниже мы покажем, что это не совсем так). Сумма проводимой сделки не разглашается, однако, очевидно, что это достаточно крупная сделка, учитывая известность компании в данном сегменте и перспективность этой фундаментальной технологии.

Давайте посмотрим видео Xsigo о том, как работает их технология сетевой виртуализации в флагманском продукте Data Center Fabric:

Продукт Xsigo Systems призван решать те же проблемы, что и Nicira NVP. В условиях виртуализации сетей и хранилищ развертывание новой виртуальной машины происходит за считанные минуты, а вот настройка сетевого взаимодействия, VLAN'ов безопасности и политик в различных сегментах сети предприятия занимает часы и дни. Решая эту проблему, продукт Data Center Fabric позволяет объединить сетевые ресурсы в единый пул и подключать виртуальные машины к нужным политикам и портам коммутаторов в несколько кликов. Все это особенно актуально для облачных провайдеров, имеющих в своем облаке десятки и сотни различных компаний, развертывающих свои виртуальные машины в собственной сетевой среде.

Поскольку из ролика как всегда непонятно, как это работает, приведем отзывы некоторых источников о том, что такое Xsigo DCF. Например, Wired пишет, что DCF - это продукт попроще, чем NVP от Nicira, и предназначен он для виртуализации ввода-вывода (I/O Virtualization) при подключении оконечного оборудования вроде HP Virtual Connect:

Although comparisons with VMware’s $1.26 billion acquisition of Nicira are inevitable, Xsigo actually makes a very different type of product. Whereas Nicira offers a tool that lets you build entire computer networks using nothing but software, Xsigo sells a simpler product called Data Centre Fabric (DCF), which is specifically designed to virtualize network cards and connections, reducing the amount of physical hardware and network cabling required to run a network of virtual machines.

....

This reduces both the amount of physical networking hardware required and the amount of cabling required. DCF is more comparable to HP’s Virtual Connect product. But Virtual Connect only works with HP hardware and DCF works with servers and hardware from multiple vendors.

Кстати, у Xsigo используется такое программно-аппаратное решение, которое находится "On top of the rack", агрегирующее сетевые интерфейсы оборудования и называющееся Xsigo I/O Director (сейчас он называется Fabric Diector):

Как мы видим, I/O Director соединяется с серверами по технологии 10G Ethernet или Infiniband. Отмечается также, что продукт Xsigo не требует использования виртуальных сетей VLAN для изоляции трафика виртуальных машин. При этом DCF не поддерживает технологию OpenFlow. На данный момент Xsigo DCF поддерживает аж пять гипервизоров (очевидно, поддержка должна быть на уровне виртуальных коммутаторов для платформы виртуализации): VMware vSphere, Citrix XenServer, Microsoft Hyper-V, Oracle VM Server и Red Hat Enterprise Virtualization.

Есть и другие мнения о том, чем за последние полгода стало решение Xsigo DCF:

Xsigo is the real SDN solution, it allows you to spin up connectivity from any server to any server on the fly in software and scales to thousands of servers. Nicira is nothing more than a tunneling technology inside legacy 30 year old switching technology, it doesn't solve the latency or speed requirements for today's datacenter nor the dynamic configuration requirements. Nicira and other openflow technologies are nothing more than a stop gap solution to get around configuring many different switch layers.

Однако большинство склоняется, все-таки, к тому, что DCF-это не SDN-решение, а более нишевая технлогия, направленная на уменьшение количества соединений и упрощения процедур реконфигурации программного и аппаратного обеспечения в случае изменений в сети (например, при изменении хранилища с FC на iSCSI).

Управление виртуальными сетями и соединениями производится из центральной консоли Xsigo Fabric Manager, который управляет виртуальными ресурсами, сетями, QoS и имеет шаблоны соеднинений для сетей виртуальных машин:

В составе решения есть также компоненты Xsigo Storage Accelerator и Performance Monitor:

Есть также и модная управлялка Xsigo XMS 3.0 для iPad:

Чуть более подробно о решении Xsigo можно прочитать в статье "Under the Hood with the Data Center Fabric".

С покупкой VMware компании Nicira стало больше разговоров о технологии VXLAN (Virtual eXtensible LAN), которая предоставляет расширенный механизм создания виртуальных сетей VLAN в крупных ИТ-инфраструктурах, объединяющих несколько датацентров компании (о ней мы уже упоминали). Разумеется, она нацелена на виртуализацию, и ее поддержка будет включена в платформу VMware vSphere в недалеком будущем. То есть VXLAN - это замена VLAN для создания прозрачной мобильной сетевой среды для виртуальных машин, имеющих возможность перемещаться между датацентрами.

Суть имеющейся сегодня проблемы заключается в том, что IP-адрес системы определяет две, по-сути разные, сущности: идентификатор системы и указатель на географическое размещение в сети (датацентр, сегмент), кроме того стандартная концепция VLAN позволяет использовать только до 4096 виртуальных сетей для логической изоляции классов систем, что в крупных инфраструктурах иногда оказывается недостаточно (особенно это касается IaaS-инфраструктур сервис-провайдеров, работающих с сотнями организаций, у каждой из которых свои VLAN).

Поэтому компании Cisco и VMware, к которым присоединились Citrix и Red Hat, разработали стандарт VXLAN, позволяющий организовать логические сети L2 поверх уровня L3 с возможностью минимального внесения изменений в существующую инфраструктуру сетевого взаимодействия в организациях. На данный момент черновик стандарта VXLAN в реализации IPv4 отправлен в организацию IETF, вскоре там будет и документ по реализации в IPv6.

Обзорный ролик по технологии VXLAN:

Образно говоря, технология VXLAN - это способ создания новых логических L2-сетей в рамках уже существующих L3-сетей. В одной VXLAN-сети виртуальная машина уникально идентифицируется двумя следующими параметрами:

• VXLAN Network Identifier (VNI) - 24-битный идентификатор виртуальной сети, а значит их всего может быть более 16 миллионов штук
• MAC-адрес машины

Соответственно, в одной VXLAN-сети не может быть машин с одинаковым MAC-адресом, но в разных VXLAN-сетях они вполне могут существовать (что актуально для виртуальных машин, MAC которых генерируется автоматически и глобально не уникален). Большое количество возможных VXLAN-сетей позволяет виртуальным машинам "путешествовать" между инфраструктурой организации и сторонними сервис-провайдерами без изменения сетевой идентификации, сохранением политик и изоляции внутри виртуальной сети безотносительно ее физического размещения (у себя или у IaaS-провайдера).

Для работы инфраструктуры VXLAN есть следующие компоненты:

• Необходима поддержка режимов Multicast, IGMP и PIM
• Идентификатор VNI внутри IP-пакета, только машины с одинаковым VNI могут взаимодействовать между собой
• Шлюз VXLAN Gateway
• Компонент VXLAN Tunnel End Point (VTEP) на стороне сервера виртуализации
• Виртуальная сеть VXLAN Segment/VXLAN Overlay

С точки зрения IP-пакета VXLAN, в сети IPv4 его размер увеличивается на 50 байт, а в сети IPv6 - на 70 байт. Работает это примерно так:

Допустим у нас есть виртуальная сеть VXLAN с VNI равным 864. Когда виртуальная машина VM1 хочет послать IP-пакет виртуальной машине VM2 происходят следующие вещи:

• VM1 по протоколу ARP посылает пакет с запросом MAC-адреса VM2
• Компонент VTEP1, размещенный на первом сервере VMware ESXi, инкапсулирует этот ARP-пакет в мультикаст-пакет, ассоциированный с виртуальной сетью с VNI 864
• Все остальные VTEP, получающие этот пакет, добавляют ассоциацию VTEP1 и VM1 в свои VXLAN-таблицы
• VTEP2  получает пакет, декапсулирует его и посылает броадкаст на портгруппы виртуальных коммутаторов, которым присвоен VXLAN c VNI 864
• VM2, находящаяся в одной из этих портгрупп, получает ARP-пакет и отвечает своим MAC-адресом
• VTEP2 на втором хосте ESXi формирует юникастовый пакет и отправляет его уже по существующему маршруту
• VTEP1 декапсулирует пакет и передает его виртуальной машине VM1

Теперь обратимся к структуре VXLAN-пакета:

В нем есть следующие заголовки (слева-направо):

Outer MAC Header (Ethernet Header)

Он содержит следующие поля:

• Destination Address - это MAC-адрес VTEP назначения, если этот VTEP является локальным по отношению к ближайшему роутеру, или MAC-адрес самого роутера, если VTEP находится за ним
• VLAN - опциональное поле с тэгом VLAN (не обязательно в VXLAN-реализации)
• Ethertype - тип пакета (для IPv4 установлен в 0×0800

Outer IP Header

• Protocol - содержит значение 0×11, чтобы обозначить, что это UDP-пакет
• Source IP - IP-адрес VTEP источника
• Destination IP - IP-адрес VTEP назначения

UDP Header

• Source Port - устанавливается передающим VTEP
• VXLAN Port - порт VXLAN IANA (еще не определен)
• UDP Checksum - контрольная сумма пакета на уровне VXLAN

VXLAN Header

• VXLAN Flags - различные флаги
• VNI - 24-битное поле с идентификатором VXLAN
• Reserved - набор зарезервированных полей

Итак, VM1 по описанному выше алгоритму узнала MAC-адрес VM2, после чего начинает ей адресно слать пакеты примерно так:

• VM1 посылает IP-пакет к VM2 с адреса 192.168.0.100 на адрес 192.168.0.101
• VTEP1 берет пакет и инкапсулирует его, добавляя следующие заголовки:
• VXLAN header с идентификатором VNI=864
• Стандартный UDP-заголовок с назначенным портом (VXLAN IANA)
• Стандартный IP-заголовок с IP-адресом VTEP назначения и признаком UDP-пакета
• Стандартный MAC-заголовок с MAC-адресом следующего устройства (next hop). В данном случае это роутер с маком 00:10:11:FE:D8:D2, который будет использовать стандартную маршрутизацию пакета по IP-сети до VTEP2.
• Далее VTEP2 получает такой пакет, распаковывает его (он узнает, что это VXLAN, так как это UDP-пакет) и вытаскивает VNI (864). Далее уже очищенный от обертки IP-пакет направляется к VM2, которая находится в портгруппе с VNI 864, перед чем VTEP убеждается, что она может получить пакет
• Виртуальная машина VM2 получает IP-пакет очищенным, как обычный IP-пакет

Таким образом, технология VXLAN, поддерживаемая в программном обеспечении платформы виртализации и роутеров позволит расширить сферу применения виртуальных сетей VXLAN в виртуальных облачных средах, где виртуальная машина сможет существовать в различных географически разделенных датацентрах, а пользователи смогут распределять нагрузку между своим частным облаком и облаком сервис-провайдера, не прибегая к переконфигурации виртуальных машин в рамках их виртуальных сетей.

Что еще можно почитать на эту тему (источники данной статьи):

• VXLAN Primer-Part 1
• VXLAN Primer-Part 2: Let’s Get Physical

Многие интересующиеся значимыми событиями, происходящими на рынке виртуализации, уже, наверное, читали о том, что VMware приобрела компанию Nicira за 1,26 миллиарда долларов (из них $1,05 млрд. - кэшем, что весьма много). Сумма этой сделки заставляет обратить на нее внимание и задуматься над тем, как ведущие компании в сфере облачных вычислений видят себе будущее частных облаков.

Для начала небольшой видео-обзор решения Nicira (основной продукт компании - Nicira Network Virtualization Platform ):

Из ролика ничего не понятно - это неудивительно, поскольку технология эта фундаментальная и весьма непростая. Начнем с проблемы, которая существует в крупных компаниях по всему миру, использующих технологии виртуализации на платформе VMware vSphere. Крутые и большие организации уже давно видят виртуализацию не только как платформу, но и как основу существования облаков в контексте абстракции вычислительных ресурсов:

Основа данной концепции такова: мы берем различное железо и хранилища, которые есть в нашем датацентре, объединяем их в общий пул с помощью платформы виртуализации серверов. Далее эти вычислительные мощности и стораджи мы отделяем от логической ценностной единицы ИТ - приложений - с помощью абстракций - виртуальных машин и виртуальных хранилищ. Общий вычислительный пул датацентра мы разрезаем на логически удобные нам единицы (пулы ресурсов) и дальше предоставляем пользователям виртуальные машины с соответствующим уровнем SLA из абстрактных сущностей, которые построены поверх оборудования и вычислительной архитектуры с определенными характеристиками. Делается это с помощью VMware vCloud Director с его концепцией виртуальных датацентров:

Но, помимо абстракции вычислительных ресурсов, нам нужно еще абстрагировать и сервисы хранения. Для этого сегодня существуют техники профилирования хранилищ (Storage Profiles) и средства автоматической балансировки нагрузки на них (Storage DRS):

Следующий аспект: виртуальные машины существуют на серверах и хранилищах уже на логическом, а не на физическом уровне (независимо от вендоров железа), как сделать так, чтобы в датацентре они были защищены политиками, да и сам периметр датацентра тоже был защищен? Ответ прост - есть семейство продуктов VMware vShield:

Прекрасно. Вроде все? Нет, не все. Невиртуализованной у нас осталась еще одна часть, а именно - сети. VMware предоставляет нам распределенный виртуальный коммутатор (Distributed vSwitch) с базовыми технологиями изоляции и контроля (Private VLAN), есть также продукт от Cisco - Nexus 1000V, который выполняет схожие функции, но обладает более широкими возможностями. Все это делается на уровне абстракции сетевых интерфейсов хост-серверов.

Однако в данном подходе нет самого главного - средств абстракции и виртуализации физического сетевого оборудования (коммутаторов, маршрутизаторов), большим парком которых применительно к виртуальным машинам нужно централизованно управлять в датацентре компании, где есть сотни виртуальных сетей, политик и конфигураций. Все это приводит к тому, что на развертывание новой виртуальной машины уходит 2-3 минуты (на сервере+хранилище), а вот на настройку сетевого взаимодействия, VLAN, безопасности, политик и прочего в забюрократизированных организациях уходит несколько дней.

Вот эту фундаментальную проблему и решает компания Nicira, так недешево доставшаяся VMware:

Суть концепции Nicira применительно к сетевому взаимодействию та же самая, что и в серверной виртуализации: собираем весь набор сетевого оборудования разных вендоров в единый пул, где уже на логическом уровне определяем виртуальные сети и политики, после чего можем цеплять их к виртуальным машинам централизованно:

Все это называется программно-определяемые сети (Software-defined networking, SDN) и работает на базе программных решений, разрабатываемых Nicira с далекого 2007 года. Интересно, что основательница VMware, Диана Грин, которую двинули с поста CEO компании, была одним из инвесторов Nicira, о чем мы писали 2 года назад. Диана вышла с неплохим профитом, а Nicira теперь позволит VMware получить законченную концепцию полной виртуализации облачного датацентра. Как нам и обещали, VMware вполне может стать "VMware of Networking". Кстати, теперь при покупке Nicira компания VMware снова двигает своего CEO.

Если тема вам интересна, можно почитать следующие материалы:

• VMware and Nicira – Advancing the Software-Defined Datacenter
• VMware acquires DynamicOps and Nicira, first steps to a heterogeneous hypervisor cloud solution?
• VMware buys Nicira for $1.05 billion (Zdnet)
• What Is Network Virtualization?
• vSwitch is the New Battleground. What Every Datacenter Operator Must Know.

Ну и следующая новость - покупка компанией VMware конторы DynamicOps (продукт Virtual Resource Manager, VRM). Эта контора была выделена из небезызвестного банка Credit Suisse и разрабатывает средства для автоматизации гибридных облаков на базе нескольких гипервизоров (что неизбежно будет в крупных организациях с приходом Hyper-V 3.0), а также средства управления сервисными архитектурами вроде Platform-as-a-Service, Database-as-a-Service и Storage-as-a-Service.

Как знают многие пользователи VMware, в новой версии платформы VMware vSphere 5 появилась возможность производить "горячую" миграцию виртуальных машин между хостами ESXi сразу по нескольким физическим сетевым адаптерам (Multi NIC vMotion). Опишем кратко особенности использования данной технологии.

При миграции ВМ в vSphere 5 есть следующие особенности:

• Поддержка до четырех одновременных миграций на адаптерах 1Gbps и до 8 одновременных миграций по 10Gbps сетевым адаптерам.
• Поддержка на хосте ESXi до 4 адаптеров 10Gbps и до 16 адаптеров 1Gbps.
• Миграция одной виртуальной машины vMotion может идти сразу по нескольким сетевым адаптерам (между ними просиходит балансировка нагрузки)
• В целом, vMotion стала работать быстрее (в подавляющем большинстве случаев, время переключения - не более 1 секунды)
• Логи ошибок vMotion стали богаче и информативнее

Миграция vMotion по нескольким сетевым адаптерам - это комплексный процесс, поскольку vSphere приходится обрабатывать различные комбинации из 1 GbE и 10 GbE адаптеров на хостах.

Перед началом vMotion сервер vCenter анализирует сетевые адаптеры на хостах VMware ESX / ESXi и определяет суммарную пропускную способность, которая доступна для миграции. Например, если у хоста 2 адаптера 1GbE и 1 адаптер 10GbE, тогда пул хоста считается равным 12 GbE. Емкость пула определяется как на исходном, так и на целевом хосте.

Далее есть несколько аспектов работы vMotion:

• Если исходный и целевой хосты имеют адаптеры 1GbE NIC, то между ними настраивается одно соединение для vMotion.
• Если исходный хост имеет 3 адаптера 1GbE NIC, а целевой хост имеет 1 адаптер 10GbE, то с исходного хоста к целевому, в его адаптер, открывается 3 параллельно работающих соединения (сокета vMotion).
• Если исходный хост имеет 15 адаптеров 1GbE, а целевой - 1 адаптер 10GbE и 5 адаптеров 1GbE, то первые 10 адаптеров исходного хоста соединяются с одним 10GbE-адаптером целевого, а дальше 5 адаптеров 1GbE соединяются на исходном и целевом хостах между собой. Таким образом, для миграций (одной или нескольких) открыто суммарно 15 соединений.
• Ну и, само собой, если на исходном хосте 2 адаптера 1GbE, а на целевом только один такой адаптер, то будет открыто только одно соединение 1GbE.

При всех этих моментах нужно помнить про ограничения из первого списка. Ну и напоследок видео про настройку vMotion по нескольким сетевым адаптерам:

И еще одно видео с комментариями EMC:

Для многих администраторов, управляющих решением для виртуализации настольных ПК предприятия VMware View, могут оказаться полезными таблицы используемых различными компонентами View портов. Таблицы подготовил Christoph Harding, работник VMware и автор блога That's my View, на основе следующих документов:

• VMware View Architecture Planning Guide (View 4.6)
• KB1012382 – TCP and UDP Ports required to access vCenter Server, ESX hosts and other network components

Perimeter Firewall Rules (правила между внешним клиентом View и Security Server)

DMZ Firewall Rules (правила между Security Server и Connection Server в демилитаризованной зоне)

Connection Server Rules (правила между Connection Server и сервером Active Directory)

Transfer Server Rules (правила связи Transfer Server с клиентами, Security и Connection серверами)

View Agent Rules (связь View Agent в гостевой ОС с клиентом и Connection Server)

View Client Rules Int (правила для внутреннего клиента View без использования Security Server)

View Client Rules Ext (правила для внешнего клиента View, работающего через Security Server)

Трафик HTTP и HTTPS можно проксировать на уровне приложения. Любой другой трафик можно проксировать через прозрачную TCP-/UDP-Proxy.

Интересную проблему тут обнаружили некоторые товарищи (а раньше вот тут). Вроде как при обычной установке VMware ESXi (в том числе, версии 4.1) для физических сетевых адаптеров (pNic) 1Gbit выставляется настройка не Auto Negotiate, а 1000 Mbit Full Duplex.

А вот лучшие практики VMware (например, KB 1004089) говорит нам, что лучшая настройка - это Auto Negotiate как на адаптере, так и на порту физического коммутатора, куда включен хост (можно использовать также и 1000<->1000):

Но вот 1000<->Auto как мы видим не является хорошей практикой, ибо Auto Negotioation включает в себя договаривание устройств не только о скорости и дуплексе, но и такие параметры, как flow control, backpressure, inter-frame packet timing (наверное, там еще страшные слова есть).

Таким образом, нужно либо на свиче также поставить настройку 1000 - Full Duplex, либо поменять на хосте VMware ESX настройки в Auto для сетевых адаптеров:

Можно сделать это также через PowerShell / PowerCLI методами:

Get-VMHostNetworkAdapter | Set-VMHostNetworkAdapter –AutoNegotiate

Можно через командную строку:

[root@server root]# esxcfg-nics -a vmnic1

Если что не так - поправьте, пожалуйста, сам я это сейчас посмотреть не могу.

Замечательный сайт myvirtualcloud.net опубликовал интересный калькулятор, который расчитывает необходимую ширину канала для пользователей виртуальных ПК VMware View 4.5, использующих свои десктопы по протоколам Microsoft RDP и Teradici/VMware PCoIP. Особенно это актуально для WAN-соединений при работе удаленных пользователей из дома, филиалов, командировок и т.п.

В качестве исходных данных рассматриваются 4 профиля нагрузки - офисные приложения без мультимедиа (тяжелые и легкие нагрузки), а также требовательные мультимедиа-приложения (также легкие и тяжелые). Расчеты основаны на рекомендациях VMware и Teradici и включают в себя необходимые требования ко всем типам трафика: картинка экрана, перенаправление USB, аудиотрафик и данные. Исходные требования таковы:

Ну а вот и сам калькулятор (приятно, что много разных параметров). Тыкаем на картинку:

Что еще рекомендую почитать:

• Оптимизация протокола PCoIP в VMware View 4.5
• Сравнение протоколов доступа к инфраструктуре VDI - Citrix, VMware, Microsoft и другие
• Производительность VMware View 4 в сетях WAN (через Internet)

При установке VMware View Composer 2.5 из комплекта VMware View 4.5 у вас могут возникнут следующие 2 вида ошибок:

• VMware View Composer - Unable to open firewal
• VMware View Composer - Unable to close firewal

То есть, если у вас выключен фаервол Windows Server, то будет ошибка "open firewall", а если включен - то "unable to close". При этом вы запускете установку под администратором.

Решение: запустить установку, нажав правой кнопкой мыши на файле установки View Composer и выбрав "Run As Administrator". Парадоксально, но факт - работает.

Бывший президент и основатель компании VMware, Диана Грин (Diane Greene), изгнанная злыми EMC-шниками со своего поста, наконец-то объявилась. Теперь она числится в списке соинвесторов у стартапа Nicira, придумывающего новую операционную систему для сетей. Лозунг компании гласит: "Если сеть - это компьютер, то где же тогда операционная система?".

Стэнфордский стартап (который уже!) Nicira не раскрывает своих планов относительно того, что это будет за продукт или услуга, но есть некоторые слухи. Типа как это некий вид распределенного виртуального коммутатора, обслуживающего сети передачи данных со своим подходом к управлению ими (вспомните, например, Cisco Nexus 1000v VSM/VEM). Типа как проблема управления сетями в скором времени станет очень насущной для cloud-провайдеров, и здесь Nicira завоюет еще не созданный рынок. Ну фиг знает, стартапы, как вы знаете, на то и стартапы - чтобы выстреливать с вероятностью 10%.

В большинстве публикаций чаще всего рассматривается виртуализация первого уровня. На одном или нескольких физических компьютерах, связанных реальными сетями, на базе некоторого ПО виртуализации функционирует множество виртуальных машин (VM), связанных виртуальными сетями (также эмулируемых при помощи ПО виртуализации), которые при необходимости связываются с реальными сетями через сетевые адаптеры физических компьютеров...

На VMware Communities появился черновик разделов документа VMware vSphere 4.0 Security Hardening Guide, являющегося основным руководством по обеспечению информационной безопасности виртуальной инфраструктуры серверов ESX и виртуальных машин.

Безопасность инфраструктуры виртуализации на ESX 4.0 и vCenter 4.0 в документе VMware vSphere 4.0 Security Hardening Guide поделена на 5 частей (кроме оглавления), каждую из которых можно скачать отдельно:

• Virtual Machines
• Host
• vNetwork
• vCenter
• Console OS (for ESX)

Компания VMware ожидает помощи от сообщества в проведении ревью документа VMware vSphere 4.0 Security Hardening Guide и внесении в него дополнений - присоединяйтесь!

Некоторым пользователям VMware vSphere 4 не хватает стандартной функциональности Distributed vSwitch (dvSwitch), который позволяет создать центральный коммутатор для всей виртуальной инфаструктуры, представляющий собой объединение виртуальных коммутаторов на хостах VMware ESX.

Специально для них, компания Cisco, близкий партнер VMware, предоставляет пользователям возможность применять специализированный виртуальный коммутатор Cisco Nexus 1000V в составе издания VMware vSphere Enterprise Plus (за отдельные деньги), который очень удобен сетевым администраторам для больших инсталляций VMware vSphere. Полный список функций распределенного коммутатора Cisco Nexus 1000V, который бывает как физическим устройством, так и виртуальным модулем (Virtual Appliance) приведен вот в этом документе.

А вот список возможностей нового релиза Cisco Nexus 1000V версии R1.2:

• Установка и настройка из GUI для виртуального модуля (плагин к vCenter Server)
• Layer 3 control между управляющим компонентом VSM и локальными агентами на ESX - VEMs
• Virtual Service Domains для классификации и сепарации трафика на сетевых устройствах
• iSCSI Multipath — поддержка множественного доступа iSCSI, анонсированного в VMware vSphere 4
• XML API - программный интерфейс для управления и мониторинга состояния коммутатора Nexus 1000V
• DHCP Snooping для проверки DHCP-сообщений и фильтрации некорректных ответов
• Dynamic ARP Inspection для проверки ARP запросов и ответов
• IP Source Guard для фильтрации трафика на сетевых интерфейсах, чтобы проверить корректность MAC и IP адресов 
• MAC Pinning для назначения номеров портов Ethernet отдельной подгруппе port channel subgroup
• Static Pinning

Скачать и попробовать Cisco Nexus 1000V R1.2 для VMware vSphere 4 можно по данной ссылке.

Как известно, в платформе виртуализации VMware vSphere 4 появился новый тип сетевой карты для виртуальных машин vmxnet3 (обзор адаптеров доступен здесь). У этой карточки есть некоторые дополнительные возможности, которые представлены в таблице ниже:

О том, что это за возможности вы можете прочитать вот по этим ссылкам...

TAM (Technical Account Manager) компании VMware Dudley Smith, известный публикацией Connections & Ports in VI3.5, сделал отличное руководство по портам, используемым в виртуальной инфраструктуре VMware vSphere / ESX. Сам документ доступен с сайта virtualinsanity.com:

Как известно, компания VMware сделала несколько нововведений в продукте VMware vSphere в части сетевого взаимодействия виртуальных машин (vNetwork). В частности, появился виртуальный сетевой адаптер VMXNET 3, который является продолжением серии виртуальных устройств VMXNET, которые используются в качестве vNIC. Эти устройства не имеют физических аналогов (то есть эмулируется собственная карта VMware), а значит их использование доступно только после установки драйверов с VMware Tools.
Таги: VMware, vSphere, vNetwork, ESX

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Многие из вас уже, должно быть, начинают думать о начале проекта по виртуализации серверов на базе платформы VMware vSphere, которая стала вполне доступной для сектора SMB (издания VMware vSphere Essentials). Кроме того, пакеты VMware vSphere Acceleration Kits со скидками для приобретающих впервые - никто не отменял (скидки 20-30% при покупке лицензий на 3-4 сервера). Но сегодня не о ценах, а о том, как правильно спланировать виртуальную инфраструктуру VMware vSphere с учетом появившихся новых технологий и возможностей VMware.

Итак, если начать планировать по этапам, вот так выглядят составляющие инфраструктуры при проектировании решения VMware vSphere 4...
Таги: VMware, vSphere, ESX, Fault Tolerance, vNetwork, DRS, Backup, ESXi, VMFS, vCenter, PowerShell